Projet Zuul de conception orientée objet en Java d'un jeu d'aventure
Forum des exercices du projet Zuul
Exercice 7.28.1
Abonné
Créer une nouvelle commande test acceptant un second mot représentant un nom de fichier (supposé se trouver dans le répertoire courant), et exécutant successivement toutes les commandes lues dans ce fichier de texte ; pour cela vous pouvez :
- lire la rubrique Plus de technique en tête de la liste des exercices
- chercher (CTRL-F) le mot "needs" pour trouver d'autres explications en bas de cette page
- lire le résumé de cours de l'exercice 7.28.3
Attention !
- Les noms des fichiers de commandes porteront forcément l'extension .txt .
- Il ne doit pas être nécessaire de taper cette extension. Par exemple, la commande test essai lira automatiquement dans le fichier essai.txt .
Ceci devra pouvoir être testé dans toutes les versions qu'il vous sera demandé de rendre.
Passons tranquillement en revue tout ce qui ne va pas dans le code ci-dessus :
- vFichier est une String, donc new Scanner(vFichier) va scanner la String et non le fichier qui porte ce nom.
Relisez plus attentivement la solution en bleu de cette page. - String mot = vScan.next();
ne va lire qu'un seul mot dans le fichier, alors qu'une commande en
comprend souvent deux. Il faut lire ligne par ligne et non mot par mot,
comme lorsqu'on tape les commandes au clavier. Les méthodes du Scanner à utiliser pour cela sont également données en bleu dans la page citée au point 1.
- if (vScan ==null) { vScan.close(); } est plutôt gênant : quand une référence est nulle, on n'a pas le droit d'écrire réf.méthode() sous peine de provoquer une NullPointerException.
- Une fois que que 3 problèmes seront corrigés, il n'y aura toujours rien d'affiché à l'écran, tout simplement parce-qu'il n'y a aucune instruction d'affichage dans ce code, ni aucun appel de méthode qui provoquerait un affichage. Ne faudrait-il pas exécuter chaque commande lue dans le fichier ?
Bonjour,
Lorsque je lance le jeu en applette, tout fonctionne normalement, mais lorsque je le lance sous la forme d'un fichier .jar, l'ordinateur n'arrive pas à accéder aux fichiers de tests et donc me le jeu me dit que le fichier n'a pas été trouvé.
Voici la ligne de code qui permet d'accéder à mon fichier test :
vScan = new Scanner (new File("tests/"+this.getSecondWord()+".txt"));
La variable vScan est mon fichier scan initialisé à null.
Merci d'avance.
La rubrique "Plus de technique" dit entre autres :
De façon générale, pour accéder à un fichier (même dans le répertoire courant), utiliser :
java.net.URL monURL = this.getClass().getClassLoader().getResource( "chemin_relatif/nom_de_fichier.extension" );
faute de quoi, le jeu ne fonctionnera pas en applette et ne pourra pas être distribué sous forme de fichier archive.
Serait-il possible d'implémenter cette fonctionnalité de test non pas en tant que commande dans le jeu, mais plutôt en tant que paramètre lors de l'exécution en ligne de commande du jeu ($ java -jar monJeu.jar --test commandes.txt) ?
En effet, cela semble plus adapté à la tache de test et nous faciliterait l'automatisation des tests globaux.
si vous voulez
Je n'arrive pas bien à comprendre ce que doit faire cette commande. Voila ce que j'ai compris en gros:
il faut créer un fichier texte dans lequel on écrit toutes les
commandes qu'on estime nécessaire de tester. Dans le code du jeu on
créer une nouvelle commande "test" qui permet de lire le-dit fichier.Et
c'est la que je ne sais plus,
faut-il mettre dans le fichier texte la
description de ce que doit faire telle ou telle commande ou bien
exécuter toutes les commandes et dans ce dernier cas concrètement que
doit faire le programme ?
Dans ton fichier, il faut que tu écrives comme si c'est l'utilisateur qui écrivait tes commandes.
Donc fait bien attention de sauter des lignes à chaque fin de commandes.
N'oublie pas que ton parser ne récupère que deux mots!
Ta fonction test doit récupérer donc les commandes mais aussi les afficher pour comprendre quelles commandes ont été saisies.
En gros ta fonction test va permettre à la fin de voir si toutes tes commandes fonctionnent correctement.
PS: Tu peux choisir l'extension que tu veux de ton fichier et ne pas le laisser forcément en extension txt.
Le but de cette commande test est bien d'exécuter toutes les commandes présentes dans le fichier de texte comme si elles avaient été tapées par le joueur.
Si vous savez faire en sorte qu'une commande tapée par le joueur s'exécute, pourquoi ne sauriez-vous pas faire en sorte qu'une commande lue dans un fichier s'exécute de la même manière ?
Un étudiant a écrit :
bonsoir
exception java.io.FileNotFoundException is never thrown in body of corresponding try statement
oui, il vous prévient qu'aucune instruction dans le bloc try ne risque de déclencher une FileNotFoundException : il faut donc supprimer le bloc try à cet endroit, ou bien englober une autre instruction qui, elle, peut déclencher cette exception.
A quel moment (ou à quelle instruction) le système peut-il dire "Je ne trouve pas le fichier que vous me demandez." ?
Un étudiant a écrit :
Bonjour monsieur, Nous avons rendu une premiere version du projet mais quand nous testons notre .jar, les fichiers de commandes sont introuvables. Comment pouvons nous resoudre ce probleme? Merci d'avance
Voir la rubrique Plus de technique pour la bonne façon d'accéder aux fichiers (notamment dans un .jar).
J'ai essayé de créer un fichier .txt afin que toutes les pièces du jeu sont visitées mais je rencontre un problème lors de la compilation.
Voici ma procédure test:
.../... code supprimé pour ne pas influencer les futurs lecteurs .../...
try {vScanner = new Scanner(this.getClass().getClassLoader().getResourceAsStream("" +vFichier +".txt"));}
catch (java.io.FileNotFoundException pException) {aGUI.println("File not found");}
.../... code supprimé pour ne pas influencer les futurs lecteurs .../...
L'erreur en question est la suivante: exception java.io.FileNotFoundException is never thrown in body of corresponding try statement, qui survient lors de la compilation de la ligne en gras.
Je ne vois pas d'où peut venir l'erreur et j'ai essayé de compiler même en ayant aucun fichier .txt dans le répertoire du projet sans succès.
Cordialement.
1) Regardons d'abord les conclusions que vous tirez du message d'erreur :
Vous avez une erreur de compilation et vous en déduisez que cela peut
avoir un rapport avec la présence ou l'absence d'un fichier .txt dans le répertoire du projet !?
Une erreur de compilation ne peut provenir que d'un problème java.
Pourquoi ne pas avoir traduit le message ? Il vous indique clairement
que l'exception FileNotFound n'est jamais lancée dans le bloc try.
2) Essayons maintenant d'expliquer ce message d'erreur :
FileNotFoundException ne peut être lancée que si l'on ouvre le fichier par
new Scanner( new File( nom_fichier ) )
Si on l'ouvre avec la technique que vous utilisez, c'est une NullPointerException qui surviendra lorsque le fichier ne sera pas trouvé.
Plutôt que de provoquer une exception, vous pouvez aussi tester que le paramètre du constructeur de Scanner n'est pas null.
Un étudiant a écrit :
Bonsoir,
je vous envoie ce message car j'aimerais avoir des précisions sur le
traitement d'une exception. Si j'ai bien compris, le principe consiste à
enfermer dans une boucle (précédée du mot clé try) un ensemble
d'instructions susceptibles d'engendrer une exception (comme
FileNotFoundException); suivie ensuite d'une autre boucle précédée par le
mot clé catch. Lorsqu'une exception est détectée, le programme quitte la
boucle try et rentre dans la boucle catch. La où j'ai du mal à comprendre
c'est comment doit on gérer cette exception?
Si elle a lieu, ne doit-on pas juste mettre comme instruction dans notre boucle
catch:
catch (Exception e){
aGui.println(e.toString());
}
qui renverrait juste le détail de l'exception e (ici FileNotFoundException)?
Ou il y a t-il d'autres moyens de traiter une exception mis à part de
l'afficher?
Au final le but est que, même s'il y a une erreur, le programme ne s'arrête
pas brutalement mais continue à s'exécuter.
cordialement,Vous avez tout à fait compris le principe : "le but est que, même s'il y a une erreur, le programme ne s'arrête
pas brutalement mais continue à s'exécuter".
Quelques précisions :
- vous confondez boucle et bloc : des instructions encadrées par des accolades s'appellent un bloc d'instructions ; une boucle est un bloc d'instructions qui se répète plusieurs fois. On parle donc de bloc try et de bloc catch.
- on peut faire autre chose que de simplement afficher "FileNotFoundException", par exemple, afficher "Je n'ai pas trouvé le fichier abcd.txt !", ou encore mieux, redemander à l'utilisateur de saisir un autre nom de fichier.
Un étudiant a écrit :
Afin d'améliorer mes tests en utilisant les chemins relatifs pour la
lecture des fichiers, il se trouve que ma gestion d'exceptions ne marche
plus. En effet, il semblerait qu'aucune des méthodes appelées par cette
ligne "java.io.InputStream vFile =
this.getClass().getClassLoader().getResourceAsStream("./pFileName.txt");
" n'envoie de FileNotFoundException.
J'ai essayé d'utiliser la IOException (j'ai fait l'import) mais rien n'y
fait, ma classe GameEngine ne compile plus à cause de l'instruction
catch qui me dit qu'aucune ligne dans le try ne renvoie de
FileNotFoundException (ni de IOException).
À la rigueur je pourrais ne pas utiliser l'InputStream et garder cette
ligne "File vFile = new File(pFileName);" mais j'aimerais bien
comprendre comment régler ce soucis...
Un étudiant a écrit :
Dois t-on créer une classe à part entière LectureFichierSimple pour
pouvoir effectuer la commande test (comme dans « Plus de technique »),
ou alors simplement importer toutes les bibliothèques nécessaires dans
la classe GameEngine (et ainsi créer un Scanner dedans) ?
Un étudiant a écrit :
Bonjour,
J'ai
essayé d'écrire une méthode test dans GameEngine
mais j'ai une erreur de compilation que je ne comprends pas :
"The possible exception of type
java.io.FileNotFoundException
needs to be handled"
On vous parle de possible exception "Fichier non trouvé" qui n'est pas gérée.
Le compilateur voit que vous utilisez une instruction susceptible de lancer cette exception
(probablement new File(...)) et veut logiquement :
- soit que vous disiez explicitement que vous ne gérez pas cette exception
(mais cela reporterait le problème dans la méthode appelante)
- soit que vous gériez effectivement cette exception par un
try/catch.
Pour savoir comment faire, lisez la partie "Lecture simple de fichiers de texte"
de la rubrique Plus de technique figurant en tête de la liste officielle des exercices.
Activer le mode édition
Paramètres
Utilisateurs inscrits
Groupes
Voir les permissions
Autres utilisateurs
Filtres
Rapport des compétences
Notes
Sauvegarde
Restauration
Importation
Réinitialiser
Compétences
Enseignant non éditeur
Réseaux sociaux